Docker Storage Drivers

    Docker storage drivers allow us to provide facilities for managing and storing images, containers, and other Docker objects efficiently on the Docker host machine. They are also termed, Graph Drivers. The Docker uses a pluggable architecture that allows them to support multiple storage drivers. Storage drivers provide ways through which we can write our workloads to the writable container layers. There are a plethora of storage drivers that Docker provides and supports. It is on us to decide which one to choose for our own workloads. Before choosing a suitable storage driver for ourselves, it’s better to understand the highlighting features of some of the top storage drivers supported by Docker. Also, by default, Docker uses the overlay2 storage driver when we install it. It is also supported by the Docker Engine Community.

    Storage Drivers Supported by Docker

    Let’s discuss the features of some of the most commonly used storage drivers in Docker.

    1. Overlay2

    • As discussed, Overlay2 is Docker’s default storage driver.
    • It is a relatively new and updated version of its parent driver called an overlay. In fact, it is more stable than the overlay driver.
    • The backup system for both these drivers is common and is known as xfs.
    • They come under the OverlayFS Linux Kernel Storage Driver. This is a modern union filesystem, akin to aufs.
    • However, in contrast to AUFS, OverlayFS is easy to implement and a lot faster.

    2. AUFS

    • AUFS is a union filesystem. By this, we mean that the AUFS file system displays branches of directories as a single directory on a single host which is known as Image layers in Docker.
    • Before Overlay2, the AUFS storage driver was the default storage driver in Docker. It was heavily used to manage and store image layers for the Ubuntu and other Debian flavors. In fact, it was the default storage driver for the 14.04 version of Ubuntu.
    • Its advantages are that it provides a relatively faster startup of containers. It also uses less disk space because it works by sharing images among multiple containers.
    • In general, it efficiently uses the memory, however, for workloads that are write-heavy, it generates high latencies when it writes to the container’s layers. This is so because it has multiple directories which need to be located and then copied.

    3. DeviceMapper

    • DeviceMapper is a block storage driver.
    • By this, we mean that DeviceMapper tends to store data in blocks of memory.
    • It is typically good for workloads that are write-heavy. This is due to the fact that the data is stored in the block level instead of the file level.

    4. BTRFS

    • The BTRFS storage driver is an integral part of the main Linux kernel.
    • This filesystem has tons of features. It allows us to perform block-level operations. It creates copy-on-write snapshots. It promotes the thin provisioning of resources such as memory.
    • These are the same features that are used when we use BTRFS storage drivers for Docker to manage and store Docker images and containers. This is the main reason why it is also an ideal candidate for Docker storage driver.

    5. ZFS

    • It is a next-generation file system that has several advantages when used in Linux kernels.
    • It has features such as compression, replication, deduplication, checksumming, snapshots, volume management, etc.
    • Due to incompatibilities in licensing between the GPL and CDDL, it is not shipped as the main Linux kernel.
    • It provides its own kernel module and tools for userspace.
    • However, until and unless we have enough experience with the ZFS file system, it is not recommended to use it as a Storage Driver for Docker in production.

    6. VFS

    • It is not a union file system. Here, each layer is categorized as a directory.
    • If we want to create a new layer, we need to create a deep copy of the previous layer.
    • This is why the performance of the VFS storage driver is quite poor and a lot of disk space is utilized. Hence, it is recommended to use only for testing purposes.
    • On the plus side, it is quite stable, robust, and suitable to work in every environment.
    • It is supported on all those file systems that have no copy-on-write feature.

    How to Change the Default Storage Driver in Docker?

    If you want to change the default Docker storage driver, you can use these commands. 1. Use the Docker info command to print the default Docker Storage Driver. 

    $ docker info

    2. Now, if we want to configure the Docker to use the ‘aufs’ storage driver instead of Overlay2, we can do that by editing the ‘daemon.json’ file located at /etc/docker/daemon.json as below.

    If this file does not already exist, you can create one. Add below configuration to the ‘daemon.json’ file. 

    {
"storage-driver":"aufs"
}

    3. Next, we need to restart the Docker daemon. We can do so using the following commands. 

    $ systemctl stop docker
$ systemctl start docker

    4. Now, we can run a container and check which driver is being used by that container. 

    $ docker run -d --name test ubuntu

    $ docker inspect test | grep -i ‘GraphDriver’ -A 3

    5. Let’s execute the docker info command again. 

    $ docker info

    We can see that the ‘aufs’ graph driver or storage driver is being used by a newly created container.

    Wrapping Up!

    There are several different storage drivers available that are supported by Docker. We have to understand the functionality of every driver and choose which driver is best suited for our workloads. We consider three high-level factors while selecting Docker’s storage driver. These are overall performance, shared storage system, and stability. In this article, we have discussed some of the most popular supported Docker Storage Drivers along with a step-by-step explanation process of how to view and change the default Storage Driver in Docker. Happy Learning!

    People are also reading:

    Previous Tutorial Next Tutorial